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ABSTRACT 

The Galileo Jupiter orbital mission using the 
Low Gain Antenna (LGA) requires a higher 
degree of spacecraft state knowledge than was 
originally anticipated. Key elements of the 
revised design include onboard buffering of 
science and engineering data and extensive 
processing of data prior to downlink. In order 
to prevent loss of data resulting from overflow 
of the buffers and to allow efficient use of the 
spacecraft resources, ground based models of 
the spacecraft processes will be implemented. 
These models will be integral tools in the 
development of satellite encounter sequences 
and the cruise/playback sequences where 
recorded data is retrieved. 
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1.0 THE GALILEO PHASE II DESIGN 

J he Galileo Phase II redesign for Jovian 
orbital operations using the Low Gain 
Antenna (LGA) is driven by the need to match 
the high data acquisition rates with the low 
spacecraft data transmission capability. Many 
changes have been made to both the 
spacecraft and the ground data systems to 
optimize the effective data transmission rate. 
Spacecraft changes include extensive redesign 
of the Command and Data Subsystem (CDS) 
flight software, modifications to the Attitude 
and Articulation Control System (AACS) 
software and selected instrument flight 
software changes. Ground modifications 


include adding noise reduction equipment at 
selected DSN sites, intrasite and intersite 
antenna arraying capability, new receivers and 
signal acquisition equipment and extensive 
ground software changes to support new data 
transmission modes. 

The changes to the flight system are numerous 
and constitute a significant redesign of the 
flight software. The primary modification to 
accommodate the low data rates was the 
switch from Time Division Multiplexed 
(TDM) telemetry modes to a packetized 
telemetry system based upon a highly 
optimized CCSDS packet definition. This 
allows a flexible, prioritized data transmission 
system, eliminating the inherent data 
redundancy of the TDM design. 

Onboard data buffering is implemented to 
allow high rate data acquisition. Central to 
this design is the Data Memory System (DMS 
- tape recorder) which will hold 900 Mbits of 
data. This will be used to store high rate data 
(remote sensing and fields and particles 
science data) acquired during satellite 
encounters and relayed to the ground during 
the orbital cruise phase between encounters. 
For onboard data manipulation and real time 
data acquisition and storage, several buffers 
are implemented in solid state memory. The 
most important are the priority buffer, which 
holds priority engineering and Optical 
Navigation (OPNAV) data, and the multi-use 
buffer, which is used for the storage and 
manipulation of Real Time Science (RTS) and 
the playback of data from the DMS. 
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Extensive data editing and compression is 
implemented to reduce the number of bits 
transmitted to the ground. The CDS can 
select or deselect data sources based upon 
mission phase and can edit many of the data 
sources. Both lossy and lossless compression 
schemes have been implemented onboard. 
Lossy compression based upon the Integer 
Cosine Transform (ICT) algorithm has been 
implemented in the AACS software and is 
used to compress images and Plasma 
instrument (PWS) data sets. Compression 
ratios of 2:1 to 80:1 can be selected. Lossless 
compression using the Rice algorithms 
(Reference 1) has been implemented for 
selected science data sets, resulting in data 
compression ratios of 1.2:1 to 5:1. 


2.0 SPACECRAFT DATA FLOW 

Figure 1 illustrates the typical data flow within 
the flight system. As illustrated, the onboard 
data buffers form key elements of the design. 
Controlling the data input to the buffers and 
the data output to the downlink are key tasks 
for the flight sequences. If the aggregate data 
input rate exceeds the data transmission rate, 
the buffers will fill. Overfilling the buffers will 
result in discarding new data. However, if 
data acquisition is controlled such that the 
buffers empty, fill data is inserted on the 
downlink, lowering downlink efficiency. 
Maintaining the delicate balance of the buffer 
fill state will be a significant challenge for 
Phase II operations. 



Figure 1 - Spacecraft Data Flow 
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The data input process has three constituent 
parts: the real time engineering (RTE) and 
OPNAV data, which is placed in the priority 
buffer, Real Time Science data (RTS) and the 
Playback data which is processed through the 
multi-use buffer. Real time data (RTE and 
RTS) is taken continuously and is controlled 
by the CDS. Data sources can be selected and 
deselected in accordance with planned 
observations and the data collection mode is 
controlled by the CDS telemetry command. 
Real time data acquisition and the downlink 
telemetry rate are controlled using the same 
command. This links the Real time data 
collection with the downlink telemetry rate via 
one of 90 selectable modes. 

The OPNAV and Playback processes are 
independent of the real time data acquisition 
process, and are intermittent activities. 
OPNAV activities occur prior to encounters, 
and place certain restrictions on both the 
multi-use buffer (where the data is processed) 
and the priority buffer (where the data is 
stored for transmission). The Playback 
process for retrieving the recorded data is 
completely new for orbital operations. In 
playback, the CDS performs autonomous 
retrieval and processing of the data from the 
DMS, controlled by a special parameter set 
called the playback tables. These tables 
contain information on the format of the 
recorded data, lists the data to be retrieved 
and the editing and compression to be 
performed on the selected data. Playback data 
is placed in the multi-use buffer for 
processing. To control the filling of the multi- 
use buffer a set of buffer pointers have been 
implemented. When playback is active and the 
buffer fill state falls below the low watermark 
(i.e. the downlink rate exceeds the data 
acquisition rate, allowing the buffer to empty) 
the CDS will autonomously control the DMS 
to replay data into the multi-use buffer. When 
the buffer fill state exceeds the high 


watermark, the CDS commands the DMS to 
cease operation and processes the raw tape 
data into completed data packets. This 
process occurs simultaneously with real time 
data acquisition and is exclusive of all other 
record activities. 


2. 1 BUFFER MODELING 

The buffer modeling task is necessary for the 
system to work. The highly interactive nature 
of the system and the statistical nature of the 
data compression algorithms necessitates an 
iterative approach to the design of spacecraft 
command sequences for orbital operations. 
With the number of independent variables that 
must be factored, and the accuracy with which 
they can be predicted, precise control of the 
buffer states will be difficult. Without ground 
based system models, the flight system could 
not be operated efficiently. 

To control the buffer fill rate, many variables 
need to be controlled. On the output side, the 
commanded downlink data rate is varied in 
discrete steps over the course of a DSN track 
to closely match the data rate capability 
(Figure 2). These data rate changes must be 
predicted well in advance and scheduled in the 
sequence. Any change to equipment 
capabilities or link performance will affect the 
data rate capability and the output from the 
buffers. 

On the buffer input, the various data sources 
must be controlled and the rates at which each 
source generates data must be predicted. This 
includes modeling which instruments are 
selected and deselected, the data editing 
algorithms and the target compression ratios. 
Each of these factors vary as a function of 
time. In addition, the compressibility of some 
of the sources is very data dependent, thus 
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Figure 2 - Downlink Telemetry Rate Change Modeling 


considerable variability in data volume is 
expected. 

The priority buffer has only two input data 
sources; the real time engineering data and 
OPNAV data. The only significant restrictions 
on buffer state for the priority buffer is the 
requirement that the buffer be empty before 
initiating an OPNAV process. The current 
priority scheme essentially guarantees that if 
the downlink rate exceeds the engineering 
acquisition rate, this state is achieved. 

The multi-use buffer requires significant 
modeling to predict its state. The modeling 
can essentially be broken down into two 
separate modeling regimes: the encounter 
phase, characterized by low downlink data 
rates and high rate RTS data acquisition with 
interspersed buffer dumps to tape, and the 
playback phase with higher downlink rates and 
with the Playback process active. 

The bulk of the scientific data is gathered 
during satellite encounters. This includes the 
remote sensing and very high rate fields and 
particles instrument data which is recorded 


directly to tape at up to 806.4 Kbps, and the 
high rate RTS data, which is processed into 
the multi-use buffer. Typically, the desired 
RTS acquisition rate well exceeds the 
downlink rate, filling the buffer. To allow 
extended high rate data acquisition without 
overflowing the multi-use buffer the Buffer 
Dump to Tape function has been implemented. 
This is a sequence controlled activity wherein 
the CDS will transfer completed Virtual 
Channel Data Units (VCDUs - Memory 
Management Units) from the multi-use buffer 
to the DMS, freeing the buffer for continued 
data acquisition. Since buffer Dump to Tape 
is a sequence controlled activity, it can be 
scheduled to occur between other DMS 
activities. Buffer management during 
encounters consists of predicting RTS data 
acquisition rates and scheduling buffer dumps 
to tape when necessary to prevent buffer 
overflow and loss of data. 

During the orbital cruise phase, data is 
retrieved from the DMS via the Playback 
process. Typically, the downlink data rate is 
higher than during encounters and the 
continuous RTS data acquisition is set to a 
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lower rate. This allows the playback process 
to transfer data from the DMS into the multi- 
use buffer, process the data and prepare it for 
downlink. Since the replay of data from the 
DMS is controlled via the buffer high and low 
watermarks, the process is self-regulating. 
The modeling task for cruise consists of 
multiple parts: insuring that the high and low 
watermarks are properly set, insuring the RTS 
data acquisition is low enough to prevent data 
loss due to buffer overflow and modeling 
playback data editing and compression to 
recover all of the significant encounter data. 

2.2 MODELING TOOLS 

The Phase II ground system has two main 
tools for predicting and controlling the data 
flow on the spacecraft. They are: SEQGEN, 
the primary sequence generation tool of the 
Mission Sequence System (MSS) and 
MIRAGE, a newly developed tool for 
processing data rate predicts and producing 
buffer models. Supporting the generation of 
sequences and the modeling effort are a suite 
of tools to automate the process. New tools 
for Phase II are TLMGEN, which provides 
automated generation of spacecraft telemetry 
rate change commands based upon predicted 
capability and the Playback Table Editor 
which generates playback table entries based 
upon the DMS tape map and models playback 
data production based upon processing 
parameters selected. These tools, along with a 
host of existing science and mission design 
tools, provide data input into the modeling 
process and are used for optimizing data flow. 

2.2.1 MIRAGE 

The MIRAGE (Mission Integration, Real time 
Analysis and Graphical Editor) modeling tool 
is based upon an earlier multi-mission 
sequence planning tool developed by the 


Sequence Automation research group at JPL. 
Plan-It-II was developed on an UNIX 
platform using LISP, and specifically 
developed to be extensible for multiple 
missions. Plan-It-II provided the capability to 
simulate functionally the operations of a 
spacecraft, allow sequences to be staged 
through the model, and rapidly and 
interactively present the impacts of the 
sequence and any proposed changes on the 
spacecraft resources. The Galileo project 
adapted the core of Plan-It-II to model the 
Phase II design. Modifications include 
incorporating Galileo specific time standards 
and the Phase II functional design into the 
model, defining new input data types, 
providing new constraint checking algorithms 
and modifications to the user interface to more 
closely resemble familiar planning tools 
currently in use. 

Mirage provides an interactive environment, 
displaying on-screen timelines of sequence 
activities and accompanying graphs showing 
the states of the spacecraft resources. It also 
provides an interface to the details of the 
science planning requests and allows the user 
to add, delete and modify these activities. 
This interaction allows the user to explore 
different approaches to a situation, varying 
parameters and displaying the results. This 
results in the rapid development of a viable 
sequence of data collection activities which 
the spacecraft can accommodate. 

MIRAGE will be used early in the science 
sequence design process to analyze the effect 
of the science observations on spacecraft 
resources. Used primarily in the Orbit Activity 
Plan (OAP) level, it will determine if a planned 
set of Real-Time and recorded observations 
generate buffer overflow conditions, monitor 
the usage of the DMS and track the allocation 
of resources to the various science 
observations. 
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MIRAGE will also play an important role 
during sequence execution. Because of the 
uncertainties involved in the 
telecommunications link modeling and 
onboard data compression, the actual data 
flow may not proceed as predicted. Sequence 
tweaking, involving modification of one or 
more data acquisition or transmission 
parameters, will need to be modeled to 
determine the overall effect on the data flow. 
Integral to this process will be the MIRAGE 
analysis of the spacecraft resources. 

2.2.2 SEQGEN 

SEQGEN is an existing sequence development 
tool which takes the GAP level inputs and 
converts the activities into command 
sequences and playback parameter tables. 
SEQGEN is responsible for enforcing many of 
the sequencing rules and constraints checking 
for certain onboard data resources and 
downlink data transmission. For the Phase II 
mission, SEQGEN was modified to generate 
the playback table entries. These parameters, 
which are independent from the spacecraft 
sequence, instruct the CDS on how the 
recorded data will be processed. Integral to 
the generation of the Playback Table entries, 
the Playback Table Editor allows modification 
of the playback parameters, adjusting data 
selection, editing and compression for the 
recorded instrument data. 

The output from SEQGEN can be routed to 
MIRAGE for modeling. This allows an 
iterative approach to the sequence generation 
process. In the early sequence design stages, 
an activity plan is produced and checked by 
MIRAGE for proper data flow. This product 
is refined into a working spacecraft sequence, 
again using MIRAGE modeling and the 
Playback Table Editor to adjust playback data 
parameters. Once the sequence is executing, 
sequence tweaks to optimize the data flow will 


be verified using MIRAGE before being sent 
to the spacecraft. 

3.0 SUMMARY 

This paper has presented the ground based 
modeling of the spacecraft processes for the 
orbital operations mission using the Galileo 
Low Gain Antenna. The redesign of the flight 
software requires a higher degree of spacecraft 
state knowledge than was originally 
anticipated. In order to optimize the data 
flow onboard the spacecraft and to the 
ground, interactive modeling of the data 
acquisition, buffering and transmission is 
required during the sequence design process 
and during sequence execution. These models 
have been developed concurrently with the 
flight software design, taking advantage of 
existing ground software where applicable and 
developing or adapting software for specific 
modeling and sequence generation functions. 
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